Generic Web Services - Extending Service Scope While Preserving Backwards Compatibility

In this article the challenge of extending the functionality of a Web service while guaranteeing backwards compatibility with old client applications is addressed. The authors contribute with a new interface design technique called ”Generic Web Services”. Using the technique service providers can extend the scope of Web services without breaking compatibility with existing clients. The goal is achieved by applying signature relaxation and interface balancing techniques to a current Web service interface. Furthermore, the authors discuss the advantages and disadvantages of generic Web services and give an example that applies the aforementioned techniques to a Web service from SAP Enterprise Services Workplace. 1 Need for Flexibility Modern businesses operate in an ever changing environment. Fast adaptation to the environment is therefore of vital importance. Since most of activities in a company are supported by IT-systems, the prerequisite of being flexible holds true for the systems too. For service-oriented systems the challenge of flexibility can be interpreted in two ways: (i) ability to substitute different services if they provide the same functionality to allow provider independence; (ii) ability to substitute different versions of the same service to allow the extension of services. The former interpretation leads to standardization of services. Provider independence is achieved by employing common standards during the development of services (Krafzig et al., 2004). For this reason SOA assumes the usage of agreed-upon open source protocols (e.g. HTTP, SOAP, XML) (Erl, 2005). The standardized communication and data representation protocols significantly lower the effort of switching service providers. However, the effort is still considerable, since different providers most likely use different business protocols (Ryu et al., 2007). This means that the same business entities (e.g. customer, sales order, address) and business processes (e.g. purchasing, invoicing, billing) from an application domain are represented differently. This in turn creates a formidable barrier to switching between service providers. The Figure 1 illustrates the situation of such incompatibility. A client cannot switch its provider by simply redirecting calls to another one because the interfaces of ChargeCreditCard Web service offered by others are different. To overcome this problem service providers must adhere to not only the agreed-upon technical, but also the business protocols. This creates the need of common business process standards. The standardization allows trading partners to conduct electronic commerce in a mutually understood way both syntactically and semantically (Damodaran, 2004). The most notable initiatives in the area of business process standardization are shown by RosettaNet1, OASIS2 and UN/CEFACT3. All three are non-profit consortia trying to establish common ebusiness standards to facilitate the automation of cross-organizational transactions. By involving key industry players and stakeholders, conducting exten1www.rosettanet.org 2www.oasis-open.org 3www.unece.org/cefact/ Figure 1: Incompatible service interfaces Figure 2: Incompatible service versions sive surveys and verifying all prospect standards in real-life business situations the consortia specify the business processes and associated documents for data exchange. The second interpretation of the flexibility challenge leads to Web service evolution management. Any successful software product inevitably goes through a series of changes during its lifecycle (Brooks, 1987). Service providers must constantly revise their portfolios in order to follow customers’ needs and add features to their services. While adding new functionality to services, providers must ensure that none of existing client applications faces incompatibilities caused by functionality updates. In general, the challenge is to ensure the substitutability of service versions, i.e. correct functioning of all ongoing client applications relying on the old version of a service after the version has been substituted with a new one. Because none of currently available design methodologies guaranties preserving backwards compatibility mismatches between Web services and client applications will likely to happen over the lifecycle of services (see Figure 2). Therefore service providers must develop techniques helping to avoid or at least minimize the problem. In this article we concentrate on the service evolution management and aim at finding a way of extending a Web service with new functionality while preserving backwards compatibility. We propose a new concept of generic Web services (GSW). In its essence the concept is an interface design technique that allows service providers to extend the functionality of services without breaking backwards compatibility. The rest of the article is structured as follows. The section 2 defines the concept of generic Web services with the help of the notion of signature relaxation, which is introduced in the subsection 2.1. The subsection 2.3 discusses the advantages and disadvantages of GWS. An example of GWS is presented in the subsection 2.2. The subsection 2.4 addresses the challenge of defining appropriate granularity level of an interface. Related work is discussed in the section 3. The section 4 concludes the article and outlines the future directions of the research. 1.1 What Causes Incompatibility When two parties exchange information they mutually follow rules prescribed by their communication protocol (Hohpe and Woolf, 2004). The more rigid the rules the more efficient the communication can be. Each party assumes that its counterpart follows these rules. However, many assumptions make the communication sensitive to any kind of change. Thus, incompatibility can be understood as a mismatch in the assumptions communicating parties make about each other and the common protocol. The next question to answer is why incompatibilities occur. In Web service architecture the roots of incompatibilities can be found on the message level. Messaging is the core of communication mechanism in service-oriented systems (Dahan, 2006). To work with a service client applications need only the address of the service and the XML schema of request and response messages. This information forms the description of a service and is included in a WSDL file that is published on the Web. Successful communication assumes that the client and the service exchange with messages of specific content and format. This assumption in turn creates a dependency between the client and the service. If the assumption is broken, the communication is jeopardized and incompatibilities are likely to occur. The reason for this possible failure is that the client will produce messages according to the older version of the communication contract. The operation calls deserialized from these messages will not match the signature of the service’s operations. In this paper we present a new concept of generic Web services that brings service providers closer to the solution of incompatibility problem. In its essence the concept is an interface design technique that allows service providers to extend the functionality of Web services while ensuring backwards compatibility. 2 Generic Web Services Service providers face the challenge of extending services with new features while preserving backwards compatibility. To avoid incompatibility a provider should prevent changes to the interfaces of their services. On the other hand adding new functionality may require changing the interfaces. How to freeze an interface and add features at the same time? To answer this question we introduce the notion of generic Web services. We define a generic Web service through the notion of signature relaxation as follows: A generic Web service is a Web service having at least one operation with relaxed signature. Signature relaxation, in turn, is the reduction of an operation’s signature rigidity. In other words, the semantics of an operation with relaxed signature is not statically defined at design time but determined dynamically at runtime through the values of input parameters. The next subsection explains the concept in detail. 2.1 Signature Relaxation A Web service is a set of operations accessible via specific end point. Each service operation is characterized with a signature. A signature is a collection of an operation’s name and two sets of types, instances of which are accepted and returned as input and output parameters respectively(Gamma et al., 1995). By analogy with (Gamma et al., 1995) the definition of a service’s interface can be derived. The set of all signatures defined by a service’s operations is known as the interface to the service. A service’s interface defines the complete set of request messages that can be sent to the service. To identify and distinguish interfaces developers use types. A type is a name used to denote a particular interface (Gamma et al., 1995). The signature of an operation is not only a syntactic characteristic but also a semantic one. Semantics of an operation can be defined as the implied meaning of the operation and is used to define its role in a system. The relationship between the semantic and syntactic aspects of signature comes from the way software is developed. To simplify code comprehension and maintenance developers try to come up with signatures (especially with names) that are selfdescribing and easy to understand. Thus, the semantics of an operation greatly influences the operation’s signature. The signature of an operation imposes restrictions upon the types and values of the operation’s parameters. This characteristic we will call the rigidity of an operation’s signature. Having defined the term rigidity we would like to come back to the term signature relaxation. It can be defined as the loosing of signature rigidity (i.e. the loosing of restrictions that the signature places on the types and values of parameters). Thus, signature relaxation is the extension of parameters’ connotation and the set of their possible values. Signature relaxation can be achieved by introducing a special sort of input parameters that will be used to define the meaning of other parameters. In this case the later parameters become controlled parameters and the former ones controlling or identity parameters (they identify the semantics of other parameters). We will call an operation with relaxed signature a generic operation. A generic interface, in turn, is an interface that has at least one generic operation. A generic Web service is a service with at least one generic operation. The next question to answer is how one can determine if a given operation is generic. A generic operation can be recognized via its identity parameters. Therefore, one should carefully examine the parameters of the operation. If there is at least one parameter that defines or extends the semantics of another, then the operation is generic. If an operation does not have identity parameters it is conceived to be fine-grained. 2.2 Using GWS in Practice In this section we present an example of how an interface could be relaxed and transformed to a generic one. This is demonstrated with the set of operations that were taken from Material Management SAP ES Workplace service interface: 1. Find Material by GTIN4 2. Find Material by ID and Description 3. Find Material by Search Text 4. Find Material By Customer Information 5. Find Material by Elements The operations perform the same kind of functionality. They all search the backend system for materials. Each operation, however, uses different criteria. The operation 5 has the most advanced functionality. It supports the criteria of all other operations. The rest of the operations perform specific search based on criteria that are reflected in the name of a corresponding operation. One may conclude that the operation 5 is the most generic and the rest operations are fine-grained ones. 4Global Trade Identification Number This, however, is not true, because the operation has no identity parameters. As can be seen all search criteria are hard coded as the operation’s input parameters5. Find Material by Elements (